Conditional workarea user interface refresh that balances performance and stability of web applications

ABSTRACT

In one embodiment, a system for conditionally refreshing workarea user interfaces (UIs) includes logic adapted to receive a request to refresh one or more workarea UIs, wherein the one or more workarea UIs are provided within a document object model (DOM), logic adapted to determine whether to reload the DOM or to refresh the one or more workarea UIs within the DOM without reloading the DOM; logic adapted to reload the DOM when it is determined to reload the DOM; and logic adapted to refresh the one or more workarea UIs without reloading the DOM when it is determined to refresh the one or more workarea UIs. Other systems, methods, and computer program products for conditionally refreshing workarea UIs are described according to more embodiments.

BACKGROUND

The present invention relates to user interfaces, and more particularly,to balancing performance and stability of web applications byconditionally refreshing a workarea user interface (UI).

In web UIs, there is a growing interest in using Page-Oriented Assembly.The term “page-oriented” implies that each task is encapsulated in itsown browser page. Each of the pages share common elements, such as acommon header. But launching a task involves at least one page load, asopposed to a more desirable Asynchronous JavaScript and eXtensiblemarkup language (XML) load, referred to as an AJAX load, which utilizesa background channel or pathway with which to load pages and/or exchangeinformation with a server. AJAX is used extensively within the page, butnot to load the page. As an example, some enterprise and/or cloudmanagement solutions, such as IBM's PureScale, may be page-oriented, andload tasks using repeated page loads. In contrast, some systems managersor storage managers, such as IBM's Storwize, may use a single,long-running page on which each task is loaded, such as via AJAX.

A page-oriented design best accommodates the extensibility of modernUIs. For example, IBM's Flex Systems Manager (FSM) console includesplugins from many different exploiters or contributors, which may becreated by different organizations, on different schedules, usingdifferent development practices, and possibly with different levels ofexpertise.

A page-oriented design helps deal with these inequalities in severalways. One way is by keeping each task in a separate page, the tasks areisolated and prevented from destabilizing the framework. Each pagerefresh completely cleans up between tasks, avoiding memory leaks andperformance degradation. In addition, by keeping each task in a separatepage, componentization is enforced so that tasks do not becomeinterdependent without using well-architected application programminginterfaces (APIs). Also, the page-oriented UI is better suited to thebrowser paradigm, naturally supporting multiple browser windows andtabs, bookmarks, and history. All of this is possible in a single-pageUI, but not as easy.

The downside of a page-oriented UI is performance. Each page must loadvery quickly, or a user will prefer a different product that does notreload pages, even if this product becomes unstable after a longsession. Web applications achieve fast page loads by getting initialcontent displayed while other content for the page is still loading.Though modern UIs operate in this way, pages may be very rich incontent, even when they are first presented. Initial views requireJavaScript libraries, which may require three seconds to load and parse,even when loaded from a browser's cache. The goal of one-second pagetransitions (relied on as an important threshold for quick UI activity)is theoretically achievable with page-oriented design, but challengingand costly.

Accordingly, a design which provides fast page transitions and stabilitywould be very beneficial.

BRIEF SUMMARY

In one embodiment, a system for conditionally refreshing workarea userinterfaces (UIs) includes logic adapted to receive a request to refreshone or more workarea UIs, wherein the one or more workarea UIs areprovided within a document object model (DOM), logic adapted todetermine whether to reload the DOM or to refresh the one or moreworkarea UIs within the DOM without reloading the DOM; logic adapted toreload the DOM when it is determined to reload the DOM; and logicadapted to refresh the one or more workarea UIs without reloading theDOM when it is determined to refresh the one or more workarea UIs.

In another embodiment, a method for conditionally refreshing workareaUIs includes receiving a request to refresh one or more workarea UIs,wherein the one or more workarea UIs are provided within a DOM,determining whether to reload the DOM or to refresh the one or moreworkarea UIs within the DOM without reloading the DOM, reloading the DOMwhen it is determined to reload the DOM, and refreshing the one or moreworkarea UIs without reloading the DOM when it is determined to refreshthe one or more workarea UIs.

Other aspects and embodiments of the present invention will becomeapparent from the following detailed description, which, when taken inconjunction with the drawings, illustrates by way of example theprinciples of the invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a network architecture, in accordance with oneembodiment.

FIG. 2 shows a representative hardware environment that may beassociated with the servers and/or clients of FIG. 1, in accordance withone embodiment.

FIG. 3 shows a method for conditionally refreshing workarea userinterfaces (UIs), according to one embodiment.

DETAILED DESCRIPTION

The following description is made for the purpose of illustrating thegeneral principles of the present invention and is not meant to limitthe inventive concepts claimed herein. Further, particular featuresdescribed herein can be used in combination with other describedfeatures in each of the various possible combinations and permutations.

Unless otherwise specifically defined herein, all terms are to be giventheir broadest possible interpretation including meanings implied fromthe specification as well as meanings understood by those skilled in theart and/or as defined in dictionaries, treatises, etc.

It must also be noted that, as used in the specification and theappended claims, the singular forms “a,” “an” and “the” include pluralreferents unless otherwise specified. It will be further understood thatthe terms “comprises” and/or “comprising,” when used in thisspecification, specify the presence of stated features, integers, steps,operations, elements, and/or components, but do not preclude thepresence or addition of one or more other features, integers, steps,operations, elements, components, and/or groups thereof.

The following description discloses several preferred embodiments ofsystems, methods and computer program products for using the samebrowser page repeatedly to load individual workarea user interfaces(UIs), either new or reloaded, until certain conditions trigger a pagereload, according to a navigational algorithm. One goal of thisalgorithm is to provide the performance of a one-page UI scheme, whilemaintaining the stability and other advantages of a page-oriented UI.Accordingly, a hybrid solution utilizes both page-oriented UI andsingle-page UI tools, while navigating between pages using page reloadswhen necessary, but otherwise by rebuilding the pages using JavaScript,Asynchronous JavaScript and eXtensible markup language (XML) (AJAX),and/or other suitable tools.

In one general embodiment, a system for conditionally refreshingworkarea UIs includes logic adapted to receive a request to refresh oneor more workarea UIs, wherein the one or more workarea UIs are providedwithin a document object model (DOM), logic adapted to determine whetherto reload the DOM or to refresh the one or more workarea UIs within theDOM without reloading the DOM; logic adapted to reload the DOM when itis determined to reload the DOM; and logic adapted to refresh the one ormore workarea UIs without reloading the DOM when it is determined torefresh the one or more workarea UIs.

In another general embodiment, a method for conditionally refreshingworkarea UIs includes receiving a request to refresh one or moreworkarea UIs, wherein the one or more workarea UIs are provided within aDOM, determining whether to reload the DOM or to refresh the one or moreworkarea UIs within the DOM without reloading the DOM, reloading the DOMwhen it is determined to reload the DOM, and refreshing the one or moreworkarea UIs without reloading the DOM when it is determined to refreshthe one or more workarea UIs.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as “logic,” “circuit,” “module” or“system.” Furthermore, aspects of the present invention may take theform of a computer program product embodied in one or more computerreadable medium(s) having computer readable program code embodiedthereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), a portable compact disc read-only memory (CD-ROM), an opticalstorage device, a magnetic storage device, or any suitable combinationof the foregoing. In the context of this document, a computer readablestorage medium may be any tangible medium that can contain, or store aprogram for use by or in connection with an instruction executionsystem, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device, such as anelectrical connection having one or more wires, an optical fiber, etc.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks. Any type ofprocessor may be used, such as a central processing unit (CPU), anintegrated circuit (IC), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA), a microprocessor, etc.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

FIG. 1 illustrates a network architecture 100, in accordance with oneembodiment. As shown in FIG. 1, a plurality of remote networks 102 areprovided including a first remote network 104 and a second remotenetwork 106. A gateway 101 may be coupled between the remote networks102 and a proximate network 108. In the context of the present networkarchitecture 100, the networks 104, 106 may each take any formincluding, but not limited to a LAN, a WAN such as the Internet, publicswitched telephone network (PSTN), internal telephone network, etc.

In use, the gateway 101 serves as an entrance point from the remotenetworks 102 to the proximate network 108. As such, the gateway 101 mayfunction as a router, which is capable of directing a given packet ofdata that arrives at the gateway 101, and a switch, which furnishes theactual path in and out of the gateway 101 for a given packet.

Further included is at least one data server 114 coupled to theproximate network 108, and which is accessible from the remote networks102 via the gateway 101. It should be noted that the data server(s) 114may include any type of computing device/groupware. Coupled to each dataserver 114 is a plurality of user devices 116. Such user devices 116 mayinclude a desktop computer, lap-top computer, hand-held computer,printer or any other type of logic. It should be noted that a userdevice 111 may also be directly coupled to any of the networks, in oneembodiment.

A peripheral 120 or series of peripherals 120, e.g., facsimile machines,printers, networked and/or local storage units or systems, etc., may becoupled to one or more of the networks 104, 106, 108. It should be notedthat databases and/or additional components may be utilized with, orintegrated into, any type of network element coupled to the networks104, 106, 108. In the context of the present description, a networkelement may refer to any component of a network.

According to some approaches, methods and systems described herein maybe implemented with and/or on virtual systems and/or systems whichemulate one or more other systems, such as a UNIX system which emulatesan IBM z/OS environment, a UNIX system which virtually hosts a MICROSOFTWINDOWS environment, a MICROSOFT WINDOWS system which emulates an IBMz/OS environment, etc. This virtualization and/or emulation may beenhanced through the use of VMWARE software, in some embodiments.

In more approaches, one or more networks 104, 106, 108, may represent acluster of systems commonly referred to as a “cloud.” In cloudcomputing, shared resources, such as processing power, peripherals,software, data, servers, etc., are provided to any system in the cloudin an on-demand relationship, thereby allowing access and distributionof services across many computing systems. Cloud computing typicallyinvolves an Internet connection between the systems operating in thecloud, but other techniques of connecting the systems may also be used.

FIG. 2 shows a representative hardware environment associated with auser device 116 and/or server 114 of FIG. 1, in accordance with oneembodiment. Such figure illustrates a typical hardware configuration ofa workstation having a central processing unit 210, such as amicroprocessor, and a number of other units interconnected via a systembus 212.

The workstation shown in FIG. 2 includes a Random Access Memory (RAM)214, Read Only Memory (ROM) 216, an I/O adapter 218 for connectingperipheral devices such as disk storage units 220 to the bus 212, a userinterface adapter 222 for connecting a keyboard 224, a mouse 226, aspeaker 228, a microphone 232, and/or other user interface devices suchas a touch screen and a digital camera (not shown) to the bus 212,communication adapter 234 for connecting the workstation to acommunication network 235 (e.g., a data processing network) and adisplay adapter 236 for connecting the bus 212 to a display device 238.

The workstation may have resident thereon an operating system such asthe Microsoft Windows® Operating System (OS), a MAC OS, a UNIX OS, etc.It will be appreciated that a preferred embodiment may also beimplemented on platforms and operating systems other than thosementioned. A preferred embodiment may be written using JAVA, XML, C,and/or C++ language, or other programming languages, along with anobject oriented programming methodology. Object oriented programming(OOP), which has become increasingly used to develop complexapplications, may be used.

One fundamental difference when you navigate from one workarea UI toanother is whether the new workarea UI will be loaded as a new pageload, or whether it will be refreshed within the same DOM. When a newDOM is loaded, any kind of garbage or junk code that was in the old DOMand anything that was causing problems, is removed. Whereas if AJAX orsome other suitable technique is used to simply refresh a workarea UIwithin the same DOM, all of the same material is potentially still inthe DOM. When a workarea UI is refreshed within the same DOM, all of theJavaScript libraries do not have to be reloaded and it saves a lot oftime. However, there are risks that over time the DOM deteriorates anditems do not get cleaned up right and there are bugs in code and thebugs start to surface. The browser technology, and specifically theJavaScript, is not robust enough to prevent this from happening.Currently used browser technology typically is not capable of running anEnterprise system, so by dumping the DOM and loading it all over againand starting with a clean slate, these issues may be periodicallyresolved.

Now referring to FIG. 3, a method 300 for conditionally refreshing aworkarea UI is shown according to one embodiment. The method 300 may beperformed in accordance with the present invention in any of theenvironments depicted in FIGS. 1-2, among others, in variousembodiments. Of course, more or less operations than those specificallydescribed in FIG. 3 may be included in method 300, as would beunderstood by one of skill in the art upon reading the presentdescriptions.

Each of the steps of the method 300 may be performed by any suitablecomponent of the operating environment. For example, in variousnon-limiting embodiments, the method 300 may be partially or entirelyperformed by an enterprise systems manager, a network controller, acomputing system, a server, a processor (such as a CPU, an ASIC, a FPGA,etc.) which may be embedded in and/or operate within a system, etc.

As shown in FIG. 3, method 300 may initiate with operation 302, where arequest to refresh a workarea UI is received. The workarea UI is part ofa UI operating within a document object model (DOM), which may bereferred to as a page or web page herein. The DOM may comprise aplurality of individual workarea UIs, each displaying content and/orbeing capable of receiving input from a user, each workarea UI beingprovided by a workarea program, application, or routine. Each workareais capable of operating and displaying any number of widgets,applications, input/output I/O modules, etc., as would be known by oneof skill in the art, and is capable of displaying in the workarea UIcontent to a display to be interacted with by a user and/or receivingcontent from a display via an I/O module provided on the workarea UIoperating within the DOM.

This request may be generated by any source, such as from a server orcomputing system providing the content, from a server or computingsystem hosting the content, from a routine or application (which may beexecuted on any server or computing system) which triggers the requestdue to some criteria being satisfied, such as a timer expiring, a useraction, etc., or any other suitable requesting source.

In one embodiment, the request may be triggered due to a user action.For example, typically, the request will be generated when the usernavigates to a new workarea UI. The request is sent in response to theuser trying to navigate (perhaps by clicking a link, typing an addressin an address field, typing a recognizable character string, etc.) froma current workarea UI, with the user's action indicating which newworkarea UI is to be loaded.

For example, at each navigation to a new page, a request may betriggered to refresh content within one or more workarea UIs. However,any trigger may be used to generate the request, such as at expirationof a timer, after a certain amount of AJAX calls, or any othertriggering event known in the art.

In operation 304, it is determined whether to reload the DOM or torefresh one or more workarea UIs within the DOM without a page reload.Any method of providing such a determination may be used. In oneembodiment, an algorithm may be used to determine whether to reload theDOM or to refresh the one or more workarea UIs within the DOM.

This algorithm may rely on one or more conditions in order to providethe decision. The one or more conditions that may be used to trigger apage reload are described below. Other conditions may be used inaddition to or in place of any conditions described herein. Of course,after implementation, a user may specify any additional conditions orremove any existing conditions from consideration, without expanding thescope of the algorithm.

-   -   1) Always or never: In this exemplary condition, each workarea        UI may include some indicator that indicates whether the        workarea UI is to be refreshed using a page reload or to rebuild        the workarea UI within the same DOM (refresh the workarea UI).        This indicator may be any suitable mechanism that is capable of        relaying such information, such as a flag, bit, handle,        configuration, etc. In one embodiment, the indicator may be a        flag, and the UI may maintain a RELOAD flag, where TRUE        indicates to always load each new workarea UI using a new page,        and FALSE indicates to rebuild each new workarea UI in the same        DOM. In other words, the flag flips between page-oriented (new        page is loaded each time) and single-page (workarea UIs are        refreshed within the same DOM) operation. The flag may default        to FALSE or TRUE, and may be switched to the alternate selection        at any time by a user. For example, if the flag defaults to        FALSE, it may be switched to TRUE in order to diagnose or avoid        stability problems. These stability problems may arise during a        development cycle or during operation in the field.    -   2) When memory leaks are detected: In this exemplary condition,        when any widgets of a DOM are destroyed, the algorithm may check        for memory leaks. In Dojo, an open source modular JavaScript        library that is publicly available, this may be accomplished by        looking through existing widgets for orphaned widgets, i.e.,        left-over widgets that no longer have parent widgets in the DOM        or no longer have parent widgets that are attached to the DOM.        Also, when constructing the new workarea UI, if one of the        widgets cannot be constructed because it is found to already        exist (i.e., its ID is already in use), this implies that the        DOM was not cleaned up from the last page load. In response to        any of these exemplary memory leaks, the navigational algorithm        may force a page reload of the DOM to provide the new workarea        UI within the DOM. An error log (preferably on the server        hosting the DOM) may track and indicate the problem for future        diagnosis.    -   3) When the workarea UI is in a “Penalty Box”: In this exemplary        condition, if a workarea UI, or all the workarea UIs from a        given exploiter or contributor (an organization which supports        individual workarea UIs), are found to be leaking memory or        otherwise destabilizing the DOM, then those workarea UIs may be        tagged “penaltyBox” to indicate that this particular workarea UI        is not functioning properly. Any time the user is navigating        away from any workarea UI that is indicated as penaltyBox, the        navigational algorithm may trigger a page refresh to reload the        DOM. One possible practice would be to place all new workarea        UIs (or exploiters) on probation in this way, until the workarea        UIs are proven mature and stable within the DOM due to a lack of        memory leaks over time.    -   4) Based on a domain of the workarea UI: In this exemplary        condition, each workarea UI may be categorized based on which        exploiter provides the workarea UI, indicating a different        domain. A domain might be “storage,” “networking,”        “virtualization,” etc. When the user is navigating inside a        particular domain, the DOM is never reloaded, instead each        effected workarea UI is refreshed within the DOM. However, when        the user crosses from a current domain to another domain, a DOM        reload occurs. This has the advantage of putting each domain        inside its own DOM, so that each exploiter (which has its own        domain) owns its own problems. In this way, exploiters may not        assign blame to one another when a problem occurs. (This is an        ongoing and frequently encountered problem in systems management        products.) This mechanism may be more easily understood by users        when any menus and context menus are organized by domains, so        that the user is allowed to learn to anticipate which tasks        trigger a page reload and which only result in a workarea UI        refresh within the DOM. Note that the basic framework pages of        the DOM are not counted as part of any one domain, and may be        navigated to and from without a reload, according to one        embodiment.    -   5) Based on time: In this exemplary condition, the navigational        algorithm may trigger a DOM reload, after a predetermined amount        of time has passed since a last reload. For example, this        condition may be triggered when 10 minutes of usage have passed,        30 minutes of usage, 1 hour, 1 day, etc. This condition may be        used to enforce good hygiene in the DOM.    -   6) Based on usage: In this exemplary condition, after a certain        amount of activity since a last page reload, the navigational        algorithm may trigger a DOM reload. Any criteria may be used to        determine usage, such as a number of workarea UI navigations,        page navigations, refreshes using AJAX, etc. In one embodiment,        when a predetermined number of active listeners and/or handles        is observed, a DOM reload may be triggered. The predetermined        number should be large enough that it implies a leak in the        listeners or handles, and cannot be triggered during normal use.        This condition may also be used to enforce good hygiene in the        DOM.    -   7) Based on performance: In this exemplary condition, when the        performance of the DOM or individual workarea UIs within the DOM        drops below a performance threshold, the navigational algorithm        may trigger a DOM reload. Any criteria may be used to determine        performance, such as an amount of resources being used to        perform tasks, processor usage, time needed to execute a task,        or any other criteria known to one of skill in the art to        indicate performance. The performance threshold may be        predetermined or may be a dynamic value based on metrics        achieved by the DOM in typical operation.

Any of the above described conditions, and those not specificallydescribed, may be initialized and/or managed using a graphical userinterface (GUI), in which a user may select certain parameters,thresholds, and/or values for any condition, and may assign certainconditions to certain workarea UIs, such that these workarea UIs will berefreshed using a page load only when the condition is satisfiedaccording to the settings in the GUI.

In operation 306, when it is determined to reload the DOM, the DOM isreloaded, e.g., the page is reloaded and all workarea UIs within thepage are reloaded, thereby providing updated workarea UIs and ensuringgood DOM hygiene and increased stability.

In operation 308, when it is determined to refresh the one or moreworkarea UIs, the one or more workarea UIs are refreshed withoutreloading the DOM, e.g., the page is not reloaded, but one or moreindividual workarea UIs are refreshed within the DOM, thereby providingone or more updated workarea UIs that are refreshed more quickly thanpossible using a DOM reload.

In one embodiment, AJAX may be used to refresh the one or more workareaUIs without reloading the DOM.

After either of operations 306 and/or 308 are executed, the method 300waits, possibly for another request to be received, at which point themethod 300 returns to operation 302. Otherwise, the method 300 is endedas no other requests are received.

According to another embodiment, experimentation and usage of thenavigational algorithm may result in triggers which are most effective,and whether new triggers need to be devised to account for situationsunforeseen prior to implementation. These new triggers may beincorporated to cause page reloads instead of simply refreshing one ormore workarea UIs within the DOM.

According to one embodiment, a system for conditionally refreshingworkarea UIs may be used. The system may include: logic adapted toreceive a request to refresh one or more workarea UIs, wherein the oneor more workarea UIs are provided within a DOM; logic adapted todetermine whether to reload the DOM or to refresh the one or moreworkarea UIs within the DOM without reloading the DOM; logic adapted toreload the DOM when it is determined to reload the DOM; and logicadapted to refresh the one or more workarea UIs without reloading theDOM when it is determined to refresh the one or more workarea UIs.

Any other embodiments and/or approaches described in regard to method300 may be included as logic in the system, according to variousimplementations.

In another embodiment, the method 300 may be implemented as a computerprogram product stored to a computer readable storage medium. Eachoperation of the method 300 may be implemented in computer readableprogram code executable and/or readable by a computer.

Although some algorithms may provide a caching function which caches acertain number of pages in the DOM in order to provide a faster reloadtime, this is generally only effective if a few of the pages will bereused heavily. When the number of pages that are used in any givensystem is too large, such as for systems management solutions, thecaching approach is not an adequate solution, on its own. In addition,over time, third parties, contributors, and exploiters may add morepages to the ecosystem, and the user may visit many new pages during anyof the various common use cases. Accordingly, more than a simple cachingfunction is needed to provide for these use cases.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

It will be clear that the various features of the foregoing systemsand/or methodologies may be combined in any way, creating a plurality ofcombinations from the descriptions presented above.

It will be further appreciated that embodiments of the present inventionmay be provided in the form of a service deployed on behalf of acustomer to offer service on demand.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A system for conditionally refreshing workareauser interfaces (UIs), the system comprising: logic adapted to receive arequest to refresh one or more workarea UIs, wherein the one or moreworkarea UIs are provided within a document object model (DOM); logicadapted to determine whether to reload the DOM or to refresh the one ormore workarea UIs within the DOM without reloading the DOM; logicadapted to reload the DOM when it is determined to reload the DOM; andlogic adapted to refresh the one or more workarea UIs without reloadingthe DOM when it is determined to refresh the one or more workarea UIs.2. The system as recited in claim 1, wherein JavaScript and/orAsynchronous JavaScript and eXtensible markup language (AJAX) is used torefresh the one or more workarea UIs without reloading the DOM.
 3. Thesystem as recited in claim 1, wherein the logic adapted to determinewhether to reload the DOM or to refresh the one or more workarea UIswithin the DOM without reloading the DOM comprises determining if one ormore conditions have been satisfied, wherein when any condition issatisfied, it is determined to reload the DOM; otherwise, the one ormore workarea UIs are refreshed without reloading the DOM.
 4. The systemas recited in claim 1, wherein the one or more conditions comprise atleast one of: it is indicated that the DOM is always reloaded whenrefreshing a particular workarea UI; a memory leak is detected; it isindicated that the one or more workarea UIs have been flagged forconsistently leaking memory; the one or more workarea UIs are from adifferent domain than a current workarea UI; a predetermined amount oftime has passed since the DOM was last reloaded; a predetermined amountof usage has taken place since the DOM was last reloaded; andperformance of the one or more workarea UIs drops below a performancethreshold.
 5. The system as recited in claim 4, wherein the one or moreworkarea UIs each comprise a flag which indicates to either: alwaysreload the DOM when refreshing the workarea UI, or never reload the DOMwhen refreshing the workarea UI.
 6. The system as recited in claim 4,wherein a memory leak is detected when any of: an orphaned widget isfound in existing widgets of the DOM, any widgets of the DOM aredestroyed, and a widget cannot be constructed because it is found toalready exist.
 7. The system as recited in claim 4, wherein a firstworkarea UI is flagged for consistently leaking memory when any workareaUI from an exploiter common to the first workarea UI is found to havecaused a memory leak in the DOM, or the first workarea UI is found tohave caused a memory leak, and wherein a page reload is required whennavigating away from a workarea UI that has been flagged forconsistently leaking memory.
 8. The system as recited in claim 4,wherein the one or more workarea UIs are from a different domain than acurrent workarea UI when the one or more workarea UIs that are beingnavigated to are provided by a different exploiter than the currentworkarea UI.
 9. The system as recited in claim 4, wherein the usage thathas taken place since the DOM was last reloaded is measured using atleast one of: a number of workarea UI navigations, DOM navigations, andrefreshes without reloads.
 10. The system as recited in claim 4, whereinthe performance threshold is either: a predetermined value or a dynamicvalue based on typical performance of the DOM.
 11. A method forconditionally refreshing workarea user interfaces (UIs), the methodcomprising: receiving a request to refresh one or more workarea UIs,wherein the one or more workarea UIs are provided within a documentobject model (DOM); determining whether to reload the DOM or to refreshthe one or more workarea UIs within the DOM without reloading the DOM;reloading the DOM when it is determined to reload the DOM; andrefreshing the one or more workarea UIs without reloading the DOM whenit is determined to refresh the one or more workarea UIs.
 12. The methodas recited in claim 11, wherein JavaScript and/or AsynchronousJavaScript and eXtensible markup language (AJAX) is used to refresh theone or more workarea UIs without reloading the DOM.
 13. The method asrecited in claim 11, wherein the determining whether to reload the DOMor to refresh the one or more workarea UIs within the DOM withoutreloading the DOM comprises determining if one or more conditions havebeen satisfied, wherein when any condition is satisfied, it isdetermined to reload the DOM; otherwise, the one or more workarea UIsare refreshed without reloading the DOM.
 14. The method as recited inclaim 11, wherein the one or more conditions comprise at least one of:it is indicated that the DOM is always reloaded when refreshing aparticular workarea UI; a memory leak is detected; it is indicated thatthe one or more workarea UIs have been flagged for consistently leakingmemory; the one or more workarea UIs are from a different domain than acurrent workarea UI; a predetermined amount of time has passed since theDOM was last reloaded; a predetermined amount of usage has taken placesince the DOM was last reloaded; and performance of the one or moreworkarea UIs drops below a performance threshold.
 15. The method asrecited in claim 14, wherein the one or more workarea UIs each comprisea flag which indicates to either: always reload the DOM when refreshingthe workarea UI, or never reload the DOM when refreshing the workareaUI.
 16. The method as recited in claim 14, wherein a memory leak isdetected when any of: an orphaned widget is found in existing widgets ofthe DOM, any widgets of the DOM are destroyed, and a widget cannot beconstructed because it is found to already exist.
 17. The method asrecited in claim 14, wherein a first workarea UI is flagged forconsistently leaking memory when any workarea UI from an exploitercommon to the first workarea UI is found to have caused a memory leak inthe DOM, or the first workarea UI is found to have caused a memory leak,and wherein a page reload is required when navigating away from aworkarea UI that has been flagged for consistently leaking memory. 18.The method as recited in claim 14, wherein the one or more workarea UIsare from a different domain than a current workarea UI when the one ormore workarea UIs that are being navigated to are provided by adifferent exploiter than the current workarea UI.
 19. The method asrecited in claim 14, wherein the usage that has taken place since theDOM was last reloaded is measured using at least one of: a number ofworkarea UI navigations, DOM navigations, and refreshes without reloads.20. The method as recited in claim 14, wherein the performance thresholdis either: a predetermined value or a dynamic value based on typicalperformance of the DOM.